User-Centred Requirements Handbook |
This section identifies different kinds of user of the system. These include:
• User groups – those who use the system directly 'hands on'. They may be the primary users who use the system frequently, or secondary users who use it more infrequently such as installers, maintainers.
• Other stakeholders – those who influence or are affected by the system, but not the actual users. They include: recipients of information, marketing staff, purchasers, support.
For each groups of users, a short description of their intended role in the system will be recorded, or how they will use the new product.
Process
Form 1.2, shown below can be used to record the list of user groups and a description of how they will use the system.
Bank customer
Will use the bank machine to access services.
Bank staff
Will be responsible for day-to-day maintenance, e.g. filling machine with notes and paper (for receipts and statements), correcting minor faults and reporting.
To complete the form:
1. Enter the name of the system at the top of the form.
2. Identify distinct user groups who have some interest or stake in the system. Try to be as inclusive as possible and consider all those parties who might be influenced by a system, or will have some influence on how it may be used.
3. Describe the role of each user in the system or how they will use the system.
4. Select the user groups for which user requirements will be specified. For each such group, tick the 'Expand' column.
5. For each subgroup, complete the following forms:
Section 1.3 User characteristics
Section 1.4 Technical environment
Section 1.5 Physical environment
Section 1.6 Social and organisational environment
Section 1.7 User goals and tasks
Please refer to RESPECT D4.2, section 3.2 for an introduction on
involving users within the design process. This will be of value when
users and stakeholders are being identified for recruitment to the
design team.
Form 1.2 - List of Users and current or expected role in system (Example)
| 1.2 Users and Stakeholders | ||
| System name: New bank machine | ||
| USERS | ROLE IN SYSTEM OR USE OF SYSTEM | EXPAND |
| Bank customers | Will use the bank machine to access services. |  |
| Bank staff | Will be responsible for day-to-day maintenance, e.g. filling machine with notes and paper (for receipts and statements), correcting minor faults and reporting major faults. | |
| Machine maintenance staff | Will perform routine maintenance every six months and will come out to deal with major faults. | |
| STAKEHOLDERS | ROLE IN SYSTEM OR USE OF SYSTEM | EXPAND |
| Bank marketing staff | Will be concerned with deciding what services to offer on the machine and what advertising to display when the machine is not in use. | |
Each user group ticked may be described in the User context forms 1.3 to 1.6
All goals for each user group will be listed in Form 1.7
General notes
The most obvious group are the end users for whom the particular system is being designed. However even this will sometimes be less than straightforward, as systems can have a range of different end users who have different objectives. It can be useful to identify subgroups of users who will have very different needs for a system. For example the transport needs of a young girl are very different from a woman accompanying her children, and the needs of the elderly and disabled traveller are also likely to be very different from those of the general population. Often assumptions are made for those who will use a system, and discussions as to the likely range of users and their attributes will be a useful design exercise.
In addition there may be indirect users who may be affected by the outcome of a direct user using the technology. The child being accompanied by the adult can be considered in this way, but in addition there may be many other indirect users of transport systems and many people other than travellers may need to consult timetables. For example, taxi drivers are major users of airport information systems, as they often take people to and from airports. Also a particular transport system will be just one stage in a long journey, and these different stages all interact. Thus it may be necessary to consider how well the timetables for different transport system work together. It is also important to try and consider the needs of other parties who will have a "stake" in a system, and what their needs may be. In the transport sector this could include a wide range of actors, including service providers and maintenance engineers.
Use whatever data you have available from analysis, customer contacts, etc., but do not be reluctant to use your imagination where data is missing. Mark such assumptions so that you remember which are assumptions and which are based on data. When you have identified user groups according to the categories listed, so that each category is represented by a set of people that you can think about in a concrete way, proceed to the next stage 'User Characteristics'.
It is difficult for stakeholders, often with little background in information systems, to formulate their requirements precisely and for a system designer to correctly mirror those requirements in the specification documentation. It is therefore imperative that requirements analysis, specification and design are treated in a disciplined way by following rigorously through the RESPECT framework.